draftとvalidでDB tableを分けて定義する
問題はoptionalなデータをどう扱うか、ということ
draftな状態ではoptionalもありうるが、
validな状態では必ず項目が埋められている
という場合に、本当にそのcolumnをNullableにして良いのか?
2パターン考えられる
draft/validを1つのテーブルで管理する
draft/validを別のテーブルで管理する
draft/validを1つのテーブルで管理する
必要なcolumnの他に、status: valid|draftのようなcolumnを持たせる
tableが1つで済む
各columnは全てNullableになってしまう
アプリケーション側で、全てがNot Nullになったことを確認し、insertする際にstatusをvalidに変更する
table側に制約をかけることを諦めることになる
アプリケーション側でデータの正しさを制御するしかない
selectする際は、このtableを一つ見れば、
すでにデータが存在するのかどうかを判断できる
当然めちゃくちゃmutableになる
draft/validを別のテーブルで管理する
valid tableにはNot Null制約を加味した正しいデータを保存できる
アプリケーション側で、全てがNot Nullになったことを確認し、
valid側にinsertする
draft側は削除しても良いが、別にどっちでも良さそう
これにもいくつかのパターンが考えられる
draft tableを、Nullableなものとして定義する
途中保存する場合、frontendから見ると、
LocalStorage
DB
らへんに保存することになる
Nullableにするぐらいなら、JSONのまま保存すれば、同じように扱える
データを取得する際に、validとdraftの両方を探さないといけない
validの方を見て存在しなかったら、draftから取ってくる、
draftにも存在しなかったら、まだ追加されていない、と判断する
draftの方は1個のtableで良いかもしれないが、validの方は複数tableになることもある
正しいが、これはこれで複雑、という感じがする
kawasima氏もJSON型を使うのが良い、と書いているmrsekut.icon
CLOB型またはJSON型にJSONとして、保存しておくのがよい。使いどころを悩むJSON型の最も適した用途である。ref /kawasima/途中保存 分けて定義しても考えることが増えすぎる
draftの存在を隠蔽するusecaaseのロジックが必要
draft用のtableを用意しないといけない
draftが、validを参照する用のカラムが必要
orderlineにカラムを追加して、draftも参照するようにしないといけない?
対象のtableを結合する際に、毎回、validが存在するかどうかをチェックしないといけない
https://gyazo.com/bc5568fc77640eaab58e53d4e385139d
他にも要件は考えられる
一度validになった後に、draftになることはあるか
少なくとも、Entityの型を定義する時は、これらは分けて定義されるはず
ならば、tableも分けて管理したほうが良いはず
valid tableから取得する際にいちいちvalidationする必要はない
じゃっかん関係ないけど、draftがあると
DBも
APIの型も
formの型も
全てoptionalになるからめちゃくちゃだるいmrsekut.icon